Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 9 pull requests #79252

Closed
wants to merge 32 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

rcvalle and others added 30 commits September 17, 2020 18:07
This section documents the exploit mitigations applicable to the Rust
compiler when building programs for the Linux operating system on the
AMD64 architecture and equivalent.
This adds `rust.description` to the config as a descriptive string to be
appended to `rustc --version` output, which is also used in places like
debuginfo `DW_AT_producer`. This may be useful for supplementary build
information, like distro-specific package versions.

For example, in Fedora 33, `gcc --version` outputs:

    gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)

With this change, we can add similar vendor info to `rustc --version`.
This commit updates the `library/backtrace` submodule which primarily
pulls in support for split-debuginfo on macOS, avoiding the need for
`dsymutil` to get run to get line numbers and filenames in backtraces.
…ns, r=steveklabnik

Add exploit mitigations chapter to the rustc book

This section documents the exploit mitigations applicable to the Rust compiler when building programs for the Linux operating system on the AMD64 architecture and equivalent. This was done for a project I'm currently working on, and I hope it'll also be helpful to others.
…=Dylan-DPC

lint: Do not provide suggestions for non standard characters

Fixes rust-lang#77273

Only provide suggestions if the case-fixed result is different than the original.
clarify rules for ZST Boxes

LLVM's rules around `getelementptr inbounds` with offset 0 are a bit annoying, and as a consequence we have no choice but say that a `Box<()>` pointing to previously allocated memory that has since been freed is UB. Clarify the docs to reflect this.

This is based on conversations on the LLVM mailing list.
* Here's my initial mail: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130452.html
* The first email of the March part of that thread: https://lists.llvm.org/pipermail/llvm-dev/2019-March/130831.html
* First email of the April part: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131693.html

The conclusion for me at least was that `getelementptr inbounds` with offset 0 is *not* the identity function, but can sometimes return `poison` even when the input is a regular pointer -- specifically, it returns `poison` when this pointer points into something that LLVM "knows has been deallocated", i.e., a former LLVM-managed allocation. It is however the identity function on pointers obtained by casting integers.

Note that there [are formal proposals](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf) for LLVM semantics where `getelementptr inbounds` with offset 0 isn't quite the identity function but never returns `poison` (it affects the provenance of the pointer but in a way that doesn't matter if this pointer is never used for memory accesses), and indeed this is likely necessary to consistently describe LLVM semantics. But with the informal LLVM LangRef that we have right now, and with LLVM devs insisting otherwise, it seems unwise to rely on this.
rustc_expand: Mark inner `#![test]` attributes as soft-unstable

Custom inner attributes are feature gated (rust-lang#54726) except for attributes having name `test` literally, which are not gated for historical reasons.

`#![test]` is an inner proc macro attribute, so it has all the issues described in rust-lang#54726 too.
This PR gates it with the `soft_unstable` lint.
…mulacrum

x.py: allow a custom string appended to the version

This adds `rust.description` to the config as a descriptive string to be
appended to `rustc --version` output, which is also used in places like
debuginfo `DW_AT_producer`. This may be useful for supplementary build
information, like distro-specific package versions.

For example, in Fedora 33, `gcc --version` outputs:

    gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)

With this change, we can add similar vendor info to `rustc --version`.
Add `core::slice::fill_with`

Tracking issue rust-lang#79221.

As suggested by `@m-ou-se` in rust-lang#70758 (comment) this implements `slice::fill_with` as a counterpart to `slice::fill`. This mirrors `Vec::resize` and `Vec::resize_with`. Thanks!

r? `@m-ou-se`
…rk-Simulacrum

std: Update the bactrace crate submodule

This commit updates the `library/backtrace` submodule which primarily
pulls in support for split-debuginfo on macOS, avoiding the need for
`dsymutil` to get run to get line numbers and filenames in backtraces.
Direct RUSTC_LOG (tracing/log) output to stderr instead of stdout.

Looks like this got missed in the initial implementation, AFAIK the old behavior was to output on stderr.
(Hit this while trying to debug `rustc` running inside a build script which was only letting stderr through)

r? `@oli-obk` cc `@davidbarsky` `@hawkw`
update miri

Fixes rust-lang#79226
Cc `@rust-lang/miri` r? `@ghost`
@rustbot rustbot added the rollup A PR which is a rollup label Nov 21, 2020
@Dylan-DPC-zz
Copy link
Author

@bors r+ p=5 rollup=never

@bors
Copy link
Contributor

bors commented Nov 21, 2020

📌 Commit 4123fb5 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 21, 2020
@bors
Copy link
Contributor

bors commented Nov 21, 2020

⌛ Testing commit 4123fb5 with merge 9793d6945e7976ae1d849524aa39e11b24eba26e...

@bors
Copy link
Contributor

bors commented Nov 21, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 21, 2020
@m-ou-se
Copy link
Member

m-ou-se commented Nov 21, 2020

#76858 failed on Apple.

@m-ou-se m-ou-se closed this Nov 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.